Referring to FIG. 1, a process 10 is schematically illustrated. A typical process 10 may have thousands of pieces of equipment 12, such as valves, vessels, pumps, pressure chambers, relief valves, etc., interconnected by piping 14. Each piece of equipment 12 can have several operating parameters, safeguards, overpressure scenarios, or the like. A Distributive Control System (DCS) 16 is typically used to monitor and control aspects of the process 10 automatically. The DCS 16 has a plurality of instruments 18 wired to the DCS 16. The instruments 18 are positioned along the process 10 and measure various process variables, such as pressure, temperature, flow, level, etc. The instruments 18 can be flow indicators, temperature sensors, pressure sensors, etc., which may or may not be associated with a piece of equipment 12. The DCS 16 typically uses instrument tags, which are numbers identifying particular instruments 18 in the process 10.
An Engineering Information Management (EIM) framework 20 is also typically used with the process 10. The EIM framework 20 has external applications 21 and a plurality of external databases 22-26, which store process information on a computer or network. The external applications 21 can include, but are not limited to, Lotus Notes™ (IBM®), Microsoft Access™ (Microsoft®), DOC 3000™ by Plant Automation Services Inc., and Uniformance™ Process History Database (PHD) by Honeywell, Inc. Briefly, DOC 3000™ is Windows-based software and is a data import tool for the Honeywell TPS and TDC3000™ systems. Uniformance PHD™ by Honeywell, Inc. is also based on Microsoft® technologies. Uniformance PHD™ provides data collection, data storage, historization, and visualization for process environments. The external databases 22-25 typically include an equipment database 22, a drawing database 23, a safe operating limit database 24, and a process history database 25. In the process industry, there is no standard structure for such databases, and the databases 22-25 can have a variety of different information depending on the process 10 or particular implementation.
The equipment database 22, which can be created in Lotus Notes™, stores details about equipment 12 used in the process 10. For example, the equipment database 22 typically contains equipment numbers or tags and descriptions of the equipment 12. The equipment tags can identify a specific piece of equipment 12 or can provide the functional location of the piece of equipment 12 in the process 10. The drawing database 23, which can be created in Lotus Notes™, stores details of the drawings of the process 10. For example, the drawing database 23 can contain drawing numbers of the process 10, revision dates, and descriptions or titles of the drawings.
The safe operating limit (SOL) database 24, which can be created in Lotus Notes™ or Microsoft Access™, stores details of safe operating limits for the process 10, such as the maximum or minimum pressure, temperature, levels, flow rates, compositions, etc. In the database 24, the safe operating limits are typically associated with the instrument tags of the instruments 18 used to measure the limits. In addition, the safe operating limits in the database may be associated with equipment 12 that should not exceed a specific safe operating limit.
Process standards and the Occupational Safety and Health Administration (OSHA) §1910.119(d)(2) (29 C.F.R. §1910.119) require that a process maintains safe upper and lower limits for various process variables and require that operators evaluate the effects of exceedances from such process variables. As noted previously, a safe operating limit (SOL) is a set limit for any operating variable, the exceedance of which has the potential of causing a hazardous situation in the process 10. Safe operating limits are established for all pressurized or otherwise potentially hazardous equipment 12 of the process 10. A safe operating limit can be inherent to the design of a piece of equipment 12. Also, a safe operating limit can be dictated by the process 10 and the interdependence of the process equipment 12. Examples of safe operating limits can include, but are not limited to, maximum allowable working temperature (MAWT), maximum allowable working pressure (MAWP), safe upper temperature limit (SUTL), safe lower temperature limit (SLTL), safe upper pressure limit (SUPL), safe lower pressure limit (SLPL), and the like. Other safe operating limits may also be established for operating variables as required and can include excess speed for steam turbines or minimum flow for pumps.
Software packages for recording the history of a process are known in the art.
Process history software is primarily directed to providing a log of process history conditions or values of process variables. Process history software records process variables measured from the various instruments 18 and stores the measurements in a process history database 25. The process variables are typically recorded at regular, predefined intervals (e.g., every minute) in the process history database 25. Typically, the process history database 25 holds a considerable amount of recorded data that is maintained for years. The process history database can be used to compare operation of the process during different time periods. If an incident does occur, the process history database can be used to investigate the event. The data in the process history database 25 typically includes instrument tags of the instruments 18, time entries for each measurement, and values of the process variables measured by the instruments 18. One example of process history software includes PHD™ by Honeywell, which stores data in an Oracle™ database.
To monitor and maintain the operating conditions of the process 10, the DCS 16 uses alarms, pressure relief valves, safety shutdowns, or other safeguards for the process 10. For example, alarms can be triggered when a process variable measured by an instrument 18 exceeds a predefined operating limit. When the alarm is triggered, the DCS 16 may automatically respond by opening a valve or performing some other action. Alternatively, the operators may take specific action when an alarm is triggered.
Software packages for storing the event history of the DCS 16 are also known in the art. The event history software creates a log of various DCS events, such as alarm events, triggered safeguards, alarm set point changes, alarm responses, etc. Examples of event history software includes Process Guard™ software by Matricon Pty. Ltd., Event Logger™ by Nikos, Inc., and AMO Suite™ by Plant Automated Systems. Event history software allows operators to review logs of triggered events, alarms, or other safeguards of the process 10. For example, for frequent alarms, which are often referred to as nuisance alarms, the operators can review the log and fix any setpoints if necessary.
Industry personnel may improperly assume that the number of triggered alarms or other safeguards offer a measure of the safety of the process 10. However, the process 10 typically has a large number of alarms or other safeguards, and some alarms or safeguards may be unnecessary, may be improperly set, or may be inadvertently omitted.
Thus, the number of triggered alarms or other safeguards may represent an improper estimate of the safety of the process 10. Therefore, a need exists in process industries for software that can be used to monitor a process 10 proactively and to determine whether the process 10 is legitimately operating safely with respect to actual equipment and process limits, independent of safeguards, and before an incident occurs.
The subject matter of the present disclosure is directed to overcoming, or at least reducing the effects of, one or more of the problems set forth above.